当面临替换现有软件系统的需求时，组织通常会陷入技术替换半途而废的循环。我们的经验告诉我们一系列模式，可以让我们打破这种循环，这些模式依赖于：刻意识别替换遗留软件的预期结果，将替换工作分解成多个部分，逐步交付这些部分，以及改变组织文化以认识到变化是不变的现实。

将单体应用分解成更小的服务时，最难的部分实际上是分解存储在单体应用数据库中的数据。要提取数据密集型服务，最好遵循一系列步骤，这些步骤始终保留数据的单个写入副本。这些步骤首先在现有单体应用中进行逻辑分离：将服务行为拆分为单独的模块，然后将数据拆分为单独的表。然后，可以将这些元素分别移至新的自治服务中。

大型机系统继续运行着世界上大部分的计算工作负载，但通常很难添加新功能来支持不断增长的业务需求。此外，使它们难以增强的架构挑战也使它们难以替换。为了降低风险，我们应该采用增量方法来替换遗留系统，逐步用现代技术实现来替换遗留功能。此策略要求我们将接缝引入大型机系统：我们可以将逻辑流转移到更新服务的点。在最近的一个项目中，我们研究了几种将这些接缝引入长期运行的大型机系统的方法。

随着单体系统变得过于庞大而无法处理，许多企业都被吸引将其分解成微服务架构风格。这是一段值得走的旅程，但并不容易。我们已经了解到，要做好这一点，我们需要从一个简单的服务开始，然后提取出基于对业务很重要且经常发生变化的垂直功能的服务。这些服务最初应该很大，并且最好不依赖于剩余的单体应用。我们应该确保迁移的每一步都代表着对整体架构的原子改进。

我的老同事 Dave Farley 一直在运营一个越来越受欢迎的关于软件开发的 YouTube 频道。这是很好的素材，与我自己的观点非常一致，毕竟他的经验对我的思想有很大影响。我们谈论了关于软件工程当前角色的一系列主题，特别关注了我目前支持的三个大型写作项目：数据网格、分布式系统模式和遗留系统替换模式。

资产捕获是开发 绞杀者模式应用 的一种策略。您可以将许多应用程序视为管理一组关键资产。工资单系统负责管理员工，交易系统负责管理交易，租赁系统负责管理租赁。要逐步切换到新系统，您可以先确定将从新系统开始使用的一组资产。通常，最适合开始的资产是简单资产（因为它们可以快速启动）或那些使用旧系统特别难以处理需求的资产。

历史或多或少都是空谈

-- 亨利·福特

我最近收到了一封来自《UML精粹》读者的不愉快的电子邮件。当一位愤怒的读者后悔购买，更不用说阅读我偶尔的智慧之语时，我的日子就不好过了。但这位读者的抱怨中有一些特别有趣的地方。他具体的抱怨是关于我“不必要的故事”。

在使用遗留系统时，识别和创建接缝非常有价值：我们可以更改系统行为而无需编辑源代码的地方。找到接缝后，我们可以使用它来打破依赖关系以简化测试，插入探针以获得可观察性，并将程序流重定向到新模块作为遗留系统替换的一部分。

我最近花了一些时间在我最喜欢的 Thoughtworks 项目之一上。这是一个始于 1998 年的项目，使用了当时最新的 J2EE 技术。多年来，它有着迷人的历史：从 EJB 开始，删除它们，离岸到班加罗尔，回到芝加哥。许多人进出过该项目，该项目的员工人数在 6 到 60 人之间变化。总的来说，该项目已经投入了超过 300 个工年的努力，代码量约为 10 万行。

当 Cindy 和我去澳大利亚时，我们在昆士兰海岸的雨林中度过了一段时间。这个地区的自然奇观之一是巨大的 绞杀榕。它们在树的上枝发芽，逐渐向下生长，直到扎根于土壤中。经过多年的生长，它们变成了奇妙而美丽的形状，同时扼杀了作为宿主的树木。